i was itching to make this a static std::array constexpr but that would've been a bigger refactor and entailed making all the global static strings in the implementation file g_str* string views or similar and update the various string concatenations in the cli to fmt::format style. didn't seem worth the effort in the end.

You mean you'd replace them with global static string_views? Don't they still need to be attached to some string stored somewhere? What would that look like?

TBH I have mixed feelings about those global strings. I kept them back when I refactored the CLI, but they're clunky, not used consistently for all options and I'm not sure this really saves us all that much. The biggest benefit is I guess preventing typos when you have to use an existing option name in a bunch more places, but that's not much.

You mean you'd replace them with global static string_views? Don't they still need to be attached to some string stored somewhere? What would that look like?

If you write static std::string_view constexpr v{"hi"} then that string literal in there already has static storage duration and so the string view can just point to that - they have constexpr support :)

So something like this works, too:

static auto constexpr opts = std::to_array<std::string_view>({
    "A", "B", "C"
});

TBH I have mixed feelings about those global strings.

Not the biggest fan of them, either. I agree, they have dubious value here... I'd be much happier with a struct that defines the properties of an option somewhere and having a couple of these.